A number of currently available computer applications offer an ability to restore an historic snapshot of a database. In effect, the application allows the ability to “time travel” by viewing a snapshot of the data at a given point in time. Other related database functionality can include the ability to aggregate on the state of many historic states of the data, which can be referred to as temporal aggregation.
In modern high performance relational databases, isolation of concurrent transactions can be an important requirement for correct execution of transactions. Without transactional isolation, concurrently executed transactions can be caused read an inconsistent intermediate state written by one or more transactions or one or more states caused by one or more transactions that is or are later aborted and rolled back. This can be referred to as a “dirty read.” Multi version concurrency control approaches can be employed to ensure consistent read operations. An important consideration for a concurrency control mechanism can be the minimization of negative performance impacts. With multi version concurrency control, concurrent read operations can advantageously see a consistent view of the database without blocking concurrent write operations. Such an approach can allow a higher degree of concurrency compared to concurrency control based on shared read locks. With multi version concurrency control, updates are implemented not by overwriting existing records but by inserting new versions. A transaction may write a new version of some data item while concurrent transactions still have read access to previous versions of the data item. Typically, some kind of timestamp (or equivalent mechanism) is associated with each version. This temporal information can be used to determine which versions are visible for which transactions. Deletions can be implemented by inserting a deletion version or by some other mechanism that indicates that the previous version is no longer visible to subsequent transactions.
To keep track of transactions and to implement timestamps for multi version concurrency control, a transaction manager or comparable functionality of a database management system can maintain two types of identifiers: a transaction identifier (TID), which is an integer number that reflects the sequence of starting points of write transactions and which is increased whenever a write transaction starts or when a read transaction is transformed into a write transaction, and a commit identifier (CID), which can be a value (e.g. an integer, a real number, etc.) that reflects the commit sequence of write transactions and that is amenable to being sorted in a sequential order. A transaction can be either a read transaction or a write transaction (which can include adding, deleting, or changing content to a table). In general, a transaction may start as a read transaction but then be promoted into a write transaction by the transaction manager. The TID can be assigned to the write transaction as its unique identifier. A TID can in some examples be used to store the transaction that made an uncommitted change. The transaction manager can internally retain a maximum CID, i.e. the sequence number of the most recent commit. When a transaction is committed, the maximum CID can be increased and the new value can be assigned to the committed transaction. The CID can thereby be considered as equivalent to a commit timestamp.